Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revision of tau quality cut configuration #30364

Merged

Conversation

swozniewski
Copy link
Contributor

PR description:

Adds parameter maxDeltaZToLeadTrack to the tau quality cut descriptions. While technically usable by producers, this parameter was not used in the past and not represented in the fillDescriptions. In recent trigger studies, it is needed.

Furthermore, the part of fillDescriptions that refers to the qualityCuts and was present in several producers is moved to the RecoTauQualityCuts class and now imported and shared by the producers.

Some deprecated helper functions are removed from the RecoTauQualityCuts class.

This is only a technical change and no changes to physics results are expected.

PR validation:

  • compiles
  • code checks pass
  • format checks pass
  • unit tests pass
  • limited matrix tests pass

Christian Veelken added 6 commits June 25, 2020 11:44
…lt disabled by setting its value to -1.0)

- declare all configuration parameters related to RecoTauQualityCuts class in RecoTauQualityCuts.cc
- removed obsolete global functions for applying quality cuts from RecoTauQualityCuts.cc
@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-30364/16419

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @swozniewski for master.

It involves the following packages:

RecoTauTag/RecoTau

@perrotta, @cmsbuild, @slava77 can you please review it and eventually sign? Thanks.
@riga this is something you requested to watch as well.
@silviodonato, @dpiparo you are the release manager for this.

cms-bot commands are listed here

@slava77
Copy link
Contributor

slava77 commented Jun 25, 2020

@cmsbuild please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Jun 25, 2020

The tests are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+1
Tested at: 4948d42
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-fa1200/7342/summary.html
CMSSW: CMSSW_11_2_X_2020-06-25-1100
SCRAM_ARCH: slc7_amd64_gcc820

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-fa1200/7342/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 36
  • DQMHistoTests: Total histograms compared: 2778915
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2778864
  • DQMHistoTests: Total skipped: 50
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 35 files compared)
  • Checked 152 log files, 16 edm output root files, 36 DQM output files

Copy link
Contributor

@slava77 slava77 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no actions are required for this PR.

However, the updates reveal some redundancy/duplication in the way how the configurations are made/used.
to which extent are the files created by fillDescriptions and modified in this PR actually used?
From a cursory check I see that some are used and some are not

  • pfTauPrimaryVertexProducer_cfi is not used
  • pfRecoTauChargedHadronProducer_cfi is used

Some cleanup/refactoring should be added to directly use the config files generated by the fillDescriptions.

@@ -10,6 +10,7 @@
maxTrackChi2 = cms.double(100.), # require track Chi2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file better be populated from a reference file created by fillDescriptions.
The dual support of the content here and in fillDescriptions is not very practical.

@slava77
Copy link
Contributor

slava77 commented Jun 30, 2020

+1

for #30364 4948d42

@cmsbuild
Copy link
Contributor

This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @silviodonato, @dpiparo (and backports should be raised in the release meeting by the corresponding L2)

@swozniewski
Copy link
Contributor Author

no actions are required for this PR.

However, the updates reveal some redundancy/duplication in the way how the configurations are made/used.
to which extent are the files created by fillDescriptions and modified in this PR actually used?
From a cursory check I see that some are used and some are not

* pfTauPrimaryVertexProducer_cfi is not used

* pfRecoTauChargedHadronProducer_cfi is used

Some cleanup/refactoring should be added to directly use the config files generated by the fillDescriptions.

I agree. We started a discussion internally how we want to include the autogenerated cfi files but did not want to delay this update. We have in mind (in addition to using only the auto-generated cfi-files of the producers) to make PFRecoTauQualityCuts create its own auto-generated cfi file (as you suggest above), where central modifications like for phase 2 can be applied and which is then shared between the producers like the current cfi for quality cuts.

@slava77
Copy link
Contributor

slava77 commented Jul 1, 2020

I agree. We started a discussion internally how we want to include the autogenerated cfi files but did not want to delay this update. We have in mind (in addition to using only the auto-generated cfi-files of the producers) to make PFRecoTauQualityCuts create its own auto-generated cfi file (as you suggest above), where central modifications like for phase 2 can be applied and which is then shared between the producers like the current cfi for quality cuts.

Some care may be needed here.
The current system would not let you to transparently use an auto-generated (helper) PFRecoTauQualityCuts_cfi from the fillDescriptions.
If a "helper" PSet is to be included in many different module definitions, then individual module fillDescriptions can include it by calling that helper::fillDescriptions method, which leaves a possibly auto-generated PFRecoTauQualityCuts_cfi useless by itself (the current situation, apparently, except that the module fillDescriptions-made files are not used directly).
The era/modifier updates will need to be added in every module fillDescriptions-generated file.
IIUC, self-contained helper support with era modifications in only one place will need that helper to become an ES or ED product producer (depending on event-data dependencies).
This way the full helper PSet will be moved out and can be modified with an era/modifier in one place.
@makortel @Dr15Jones what is your expectation/preference?

@@ -91,6 +92,9 @@ namespace reco {
return output;
}

/// Declare all parameters read from python config file
static void fillDescriptions(edm::ParameterSetDescription& descriptions);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to rename this function to

Suggested change
static void fillDescriptions(edm::ParameterSetDescription& descriptions);
static void fillPSetDescription(edm::ParameterSetDescription& descriptions);

to follow a convention used elsewhere (including the helper plugins). The suggested name also signifies that the function fills a description for one PSet instead of arbitrary number of modules.

@makortel
Copy link
Contributor

makortel commented Jul 1, 2020

what is your expectation/preference?

I don't really have much to add. When a helper class (needing configuration) are used directly by many modules, and if it is expected that helper to configured consistently between the modules, any customization on the configuration of the helper needs to be repeated.

The repetition can be avoided by moving the helper algorithm to ED/ES product, in which case the configuration of the ED/ESProducer can be customized in a single place. The established practice is that if the helper needs event data, a new helper object should be produced on each event. If the helper does not need data from any of event, lumi, or run, it would be placed in EventSetup. In principle soon (after #30117 gets merged), a helper that depends only on configuration could be produced in beginProcessBlock transition.

@silviodonato
Copy link
Contributor

+1

@cmsbuild cmsbuild merged commit 0fdb1ad into cms-sw:master Jul 3, 2020
@mbluj mbluj deleted the CMSSW_11_2_X_tau-pog_QCutsCleaning branch October 10, 2023 10:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants